第13章 コンポーネントの凝集性

凝集性：どのクラスをどのコンポーネントに含めるか

再利用・リリース等価の原則（REP）

再利用可能なコンポーネント

リリース番号

（-> リリースを選んで全部使う。全再利用の原則につながる）

別の観点

ひとつのコンポーネントを形成するクラスやモジュールは、まとめてリリース可能でなければいけない (Kindle の位置No.1693-1694)

（習慣として、継続的インテグレーションが通ったらリリースする）

閉鎖性共通の原則（CCP）

単一責任の原則の言い換え

クラスを変更する理由が複数あるべきではない

-> コンポーネントを変更する理由が複数あるべきではない

同じタイミング、同じ理由で変更するものはひとまとめにすること。変更のタイミングや理由が異なるものは別々に分けること。(Kindle の位置No.1731-1732)

同じタイミングで変更されることが多いクラスはひとつにまとめておけ (Kindle の位置No.1716-1717)

デプロイの作業量を最小限にできる

オープン・クローズドの原則とも関連

閉鎖性＝クローズド

変更の種類が似ているクラスをひとつのコンポーネントにまとめる

（IMO：ひとつのコンポーネントに閉じるが、変更には開いている）

全再利用の原則（CRP）

一緒に用いられることが多いクラスやモジュールは同じコンポーネントにまとめよ (Kindle の位置No.1736-1737)

例：コンテナクラスと対応するイテレータ

コンポーネントに依存するのであれば、コンポーネントに含まれるすべてのクラスに依存するようにしておきたい (Kindle の位置No.1751-1752)

ひとつのクラスだけしか使わないコンポーネントの依存はNG

密結合していないなら同じコンポーネントにまとめるべきでない

インターフェイス分離の原則

使っていないメソッドを持つクラスに依存しない

-> 使っていないクラスを持つコンポーネントに依存しない

コンポーネントの凝集性のテンション図

3つの原則のバランスを上手くとる（図13-1）

REPとCCPはコンポーネントを大きくする方向

CRPはコンポーネントを小さくする方向

図は2つだけを採用したときの副作用も示される

プロジェクトのコンポーネントの構造が経過時間や成熟度によって変わる (Kindle の位置No.1781-1782)

プロジェクトの初期はCCPとCRP（図の右側）

再利用性が低下は受け入れた状態

開発しやすさのほうが重要

プロジェクトが進み、別のプロジェクトから利用されると、図の左側へ（REPとCRP）

変更すべきコンポーネントが増加していく

（まとめより）開発時の利便性と再利用性のトレードオフ

最適な落としどころは常に変わり続ける。(Kindle の位置No.1790)